In order for two or more computer systems to communicate with each other, the systems use a language or “protocol” that is understood by each system. During such communication, information comprising the identity of the person/device that initiated the transaction is provided via such a protocol, as part of the message. When the two or more computer systems process this identity information differently, due to differing protocols or otherwise, the computer systems may be inoperable, leading to organizations being unable to communicate. While several different standard identity communication (e.g., single sign-on or “SSO”) protocols have been created for varying situations to alleviate this situation, the different standards do not interoperate. For example, several different standards have emerged to enable single sign-on across web applications, including SAML, Shibboleth, OpenID, WS-Federation, and OpenID Connect. Each of these protocols enables an end-user to access varying web applications provided by different organizations with a single log-in. However, the protocols are not interoperable, so an organization that has chosen to use the SAML protocol for SSO often cannot provide SSO to another organization that chose a non-SAML SSO protocol such as, but not limited to, OpenID. As shown by this example, the result is that many computer systems cannot communicate with each other because they were built to speak disparate SSO protocols and are therefore unable to authenticate the users from each other's system.
In addition to the varying separate SSO protocols used throughout the industry, there are often several different incompatible versions of any single SSO protocol. For example, an organization may implement version 1.1 of the SAML protocol and not be able to interoperate with other organizations that implemented SAML 2.0, created to enhance that protocol's capability. The result is that it requires a very significant time and money investment for an organization to integrate all of their technology internally, and even more of an investment in time and money to set up this kind of SSO integration between organizations. This proliferation of approaches to user and session identity management has made it very difficult to adopt the technology in a way that enables collaboration between enterprises.
In addition to the inability of companies to interact with each other due to the different identity protocols being implemented, identity information may also be conveyed in varying ways which are not accepted across protocols during web service calls made between two computer systems. The two current standards used by these web service calls, SOAP and REST, each have a variety of ways of including the necessary identity information in their requests. This variance makes it very difficult for one organization (e.g., a company using SOAP with WS-Security) to make a web service call in order to obtain data from a second organization's computing infrastructure when the second organization has tools and technology for using REST with OAuthV2 for security. As a result, if the organizations are to work together in this technical way, one of them will have to make a significant investment to modify their infrastructure to provide/consume the identity information the way their partner expects.